Structs with no fields or all-ZST fields are ZSTs by DanielEScherzer · Pull Request #2262 · rust-lang/reference

DanielEScherzer · 2026-05-05T19:15:14Z

Guarantee that structs with Rust representation and with no fields, or where all fields are ZSTs, are themselves ZSTs.

Guarantee that enums with Rust representation with a single struct-like variant with no fields, or where all fields are ZSTs, are themselves ZSTs.

traviscross · 2026-05-06T07:32:39Z

cc @RalfJung @rust-lang/opsem

theemathas · 2026-05-06T08:00:18Z

+For [structs] with no fields, or where all fields are [zero-sized], it is further guaranteed that the structs are themselves [zero-sized].
+
+r[layout.repr.rust.enum-struct-like-zst]
+For [enums] (without a primitive representation specified) with a single struct-like variant with no fields or where all fields are [zero-sized], the enum itself is [zero-sized].


Seems bizarre to guarantee this for struct-like variants but not unit-like variants or tuple-like variants.

View changes since the review

RalfJung · 2026-05-06T11:38:05Z

That seems reasonable to me (specifically for repr(Rust); not necessarily for other reprs). Someone should check whether it is honored by -Zrandomize-layout.

traviscross · 2026-05-06T15:20:35Z

We talked about this in the lang call today. Let's propose to do this with the correction that, for enums, we mean those repr(Rust) enums without a primitive representation specified and that have a single field-struct-like variant, a single unit-struct-like variant, or a single tuple-struct-like variant where the struct-like thing has no fields or where all of the fields are zero-sized.

@rfcbot fcp merge lang

rust-rfcbot · 2026-05-06T15:20:37Z

@traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

Concerns:

~~check-randomize-layout~~ resolved by Structs with no fields or all-ZST fields are ZSTs #2262 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

traviscross · 2026-05-06T15:24:14Z

@rfcbot concern check-randomize-layout

tmandry · 2026-05-06T15:25:22Z

This seems stronger than what we guarantee for non-ZST structs, which require #[repr(transparent)] to have the same representation as the inner type. In the lang meeting, @steffahn pointed out that the non-ZST case is harder because certain types get passed in registers, etc.

I don't see a reason not to make this guarantee, and it seems like a useful one, so let's do it.

@rfcbot reviewed

zachs18 · 2026-06-15T06:21:55Z

Should we also guarantee that zero-variant repr(Rust) enums are ZSTs? They currently are in practice.

Someone should check whether it is honored by -Zrandomize-layout.

Yes, I believe it is. IIUC the current implementation of -Zrandomize-layout only reorderes fields, never introduces any "extra" padding¹. Shuffling the field order cannot make a ZST into a non-ZST (or vice versa), so the current implementation upholds the proposed guarantees.

reasoning

When the -Zrandomize-layout flag is enabled, the compiler enables ReprFlags::RANDOMIZE_LAYOUT for types defined in that crate (src) (unstable_opts.randomize_layout is not mentioned anywhere else in the compiler).

ReprFlags::RANDOMIZE_LAYOUT is mentioned in four places in the compiler:

When it is declared (src)
When it is enabled (see previous section)
In SizeSkeleton, which IIUC ignores it when computing the size of generic NPO-optimized enums and newtype structs/enums (src)
1. NPO is irrelevant here (there are no ZSTs eligible for NPO optimization)
2. For newtypes over ZSTs, this should correctly give a ZST size regardless of RANDOMIZE_LAYOUT
When it is used in ReprOptions::can_randomize_type_layout which returns !self.inhibit_struct_field_reordering() && self.flags.contains(ReprFlags::RANDOMIZE_LAYOUT) (src)

ReprOptions::can_randomize_type_layout is used in one place in the compiler: in layout computation (fn univariant_biased) where the field list (excluding the unsized tail) is shuffled if it returns true (instead of being optimized by sorting by alignment) (src). Shuffling (or sorting) the field order cannot make a ZST into a non-ZST (or vice versa), so the current implementation upholds the proposed guarantees.

I opened a PR rust-lang/rust#157905 to update the comments in some of the places where -Zrandomize-layout is implemented referring back to this FCP to ensure that future changes to -Zrandomize-layout do not break these guarantees.

~~@/rustbot label I-lang-nominated~~

~~Nominating for possibly resolving the -Zrandomize-layout concern (and maybe considering zero-variant repr(Rust) enums) ~~

other than the padding necessary to make fields aligned, and since 0 is a multiple of any alignment, this padding is never added for struct-like layouts if all fields are zero-sized ↩

rustbot · 2026-06-17T04:21:51Z

Error: Label I-lang-nominated can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

traviscross · 2026-06-17T07:15:55Z

@rfcbot resolve check-randomize-layout

Thanks @zachs18. I looked into this and concur.

Should we also guarantee that zero-variant repr(Rust) enums are ZSTs? They currently are in practice.

Probably. Let's do that in a separate Reference PR.

rust-rfcbot · 2026-06-17T07:16:02Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rust-rfcbot · 2026-06-27T07:19:43Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

chorman0773 · 2026-06-27T16:39:54Z

without a primitive representation specified

This wording doesn't seem super clear on whether or not repr(C) enums are excluded (which they should be, because they are implicitly repr(C, Int), where Int is a target-specific integer type, but that isn't "specified" in the repr attribute).

DanielEScherzer · 2026-06-30T01:49:26Z

We talked about this in the lang call today. Let's propose to do this with the correction that, for enums, we mean those repr(Rust) enums without a primitive representation specified and that have a single field-struct-like variant, a single unit-struct-like variant, or a single tuple-struct-like variant where the struct-like thing has no fields or where all of the fields are zero-sized.

If/when FCP passes I'll apply this correction

Done, fa61cbd

@rustbot ready

DanielEScherzer · 2026-07-07T18:35:38Z

without a primitive representation specified

This wording doesn't seem super clear on whether or not repr(C) enums are excluded (which they should be, because they are implicitly repr(C, Int), where Int is a target-specific integer type, but that isn't "specified" in the repr attribute).

In the glossary, the new entries start with - `repr(Rust)` [structs] and - `repr(Rust)` [enums] s so I think it is clear there

On the type layout page, the entries are under the ### The `Rust` representation section heading; the other layout rules there don't explicitly note that they are for the rust representation because that is clear from the location and context

traviscross · 2026-07-07T19:08:16Z

+For [structs] with no fields or where all fields are [zero sized], it is further guaranteed that the structs are themselves [zero sized].
+
+r[layout.repr.rust.enum-struct-like-zst]
+For [enums] (without a primitive representation specified) with a single field-struct-like variant, a single unit-struct-like variant, or a single tuple-struct-like variant and where the struct-like thing has no fields or where all of the fields are [zero sized], the enums themselves are [zero sized].


Let's add links to cross-reference each of these, here and in the glossary.

View changes since the review

traviscross · 2026-07-07T19:08:54Z

+For [structs] with no fields or where all fields are [zero sized], it is further guaranteed that the structs are themselves [zero sized].
+
+r[layout.repr.rust.enum-struct-like-zst]
+For [enums] (without a primitive representation specified) with a single field-struct-like variant, a single unit-struct-like variant, or a single tuple-struct-like variant and where the struct-like thing has no fields or where all of the fields are [zero sized], the enums themselves are [zero sized].


Let's add links to cross-reference each of these, here and in the glossary.

View changes since the review

New rule `layout.repr.rust.struct-zst` adds the guarantee that `repr(Rust)` structs with no fields or all ZST fields are ZSTs. New rule `layout.repr.rust.enum-struct-like-zst` adds the guarantee that `repr(Rust)` enums with a single struct-like variant with no fields or all ZST fields are ZSTs. The glossary entry for ZSTs is expanded with references to these guarantees and examples.

traviscross · 2026-07-07T19:20:22Z

Thanks @DanielEScherzer.

rustbot added the S-waiting-on-review Status: The marked PR is awaiting review from a maintainer label May 5, 2026

DanielEScherzer force-pushed the zst-structs branch from ba89b4f to 51e8478 Compare May 5, 2026 19:48

DanielEScherzer changed the title ~~New rule: items.struct.zst~~ New rules for ZSTs May 5, 2026

DanielEScherzer force-pushed the zst-structs branch from 51e8478 to 9c34b1e Compare May 5, 2026 19:50

traviscross changed the title ~~New rules for ZSTs~~ New rules for structs with no fields May 5, 2026

traviscross changed the title ~~New rules for structs with no fields~~ Structs with no fields are ZSTs May 5, 2026

traviscross changed the title ~~Structs with no fields are ZSTs~~ Structs with no fields or all-ZST fields are ZSTs May 5, 2026

DanielEScherzer force-pushed the zst-structs branch 2 times, most recently from 6a2c83a to 5011dcd Compare May 5, 2026 20:26

traviscross added I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-1 Lang team prioritization drag level 1. T-lang Relevant to the language team. labels May 5, 2026

theemathas reviewed May 6, 2026

View reviewed changes

rust-rfcbot added proposed-final-comment-period disposition-merge labels May 6, 2026

traviscross added I-lang-radar Items that are on lang's radar and will need eventual work or consideration. and removed I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-1 Lang team prioritization drag level 1. labels May 13, 2026

zachs18 mentioned this pull request Jun 15, 2026

Update comments and add tests for -Zrandomize-layout for some guaranteed ZSTs rust-lang/rust#157905

Draft

rust-rfcbot added the final-comment-period label Jun 17, 2026

rust-rfcbot added finished-final-comment-period and removed final-comment-period labels Jun 27, 2026

rust-rfcbot added the to-announce label Jun 27, 2026

RalfJung mentioned this pull request Jun 29, 2026

defining zero-sized structs rust-lang/unsafe-code-guidelines#37

Closed

DanielEScherzer force-pushed the zst-structs branch from 67b1047 to fa61cbd Compare June 30, 2026 01:46

rustbot added S-waiting-on-review Status: The marked PR is awaiting review from a maintainer and removed S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. labels Jun 30, 2026